1. DBA can define diskquota of a user/schema  on a specified tablespace.
2. For tablesapce level diskquota, DBA can define per-segmet diskquota ratio to avoid data skew.
3. Add hard-limit diskquota option. DBA can turn on/off hard-limit based on the requirement. DBA can tune the hardlimit check frequency to avoid big performance regression.

postgres=# create table foopart (a int, b int) distributed by (a) partition by range(a) (start(1) end(3) every(1));
NOTICE:  CREATE TABLE will create partition "foopart_1_prt_1" for table "foopart"
NOTICE:  CREATE TABLE will create partition "foopart_1_prt_2" for table "foopart"
CREATE TABLE
postgres=# insert into foopart select i%2+1, i from generate_series(1,50)i;
INSERT 0 50
postgres=# select gp_toolkit.gp_skew_details('foopart_1_prt_1'::regclass);
 gp_skew_details
-----------------
 (16387,2,0)
 (16387,0,0)
 (16387,1,25)
(3 rows)

postgres=# select gp_toolkit.gp_skew_details('foopart_1_prt_2'::regclass);
 gp_skew_details
-----------------
 (16392,0,25)
 (16392,1,0)
 (16392,2,0)
(3 rows)

gpadmin=# \d pxf_trino_memory_names
  External table "public.pxf_trino_memory_names"
 Column |            Type             | Modifiers
--------+-----------------------------+-----------
 id     | integer                     |
 now    | timestamp without time zone |
Type: readable
Encoding: UTF8
Format type: custom
Format options: formatter 'pxfwritable_import'
External options: {}
External location: pxf://postgresql.public.trino_test?PROFILE=jdbc&SERVER=trino
Execute on: all segments

gpadmin=# SELECT * from pxf_trino_memory_names limit 3;
 id |            now
----+---------------------------
  1 | 2021-09-21 16:35:55.67971
  2 | 2021-09-21 16:35:55.67971
  3 | 2021-09-21 16:35:55.67971
(3 rows)

    <property>
        <name>jdbc.connection.property.SSLKeyStorePath</name>
        <value>/usr/local/pxf-gp5/servers/trino/trino.matt.lab.pem</value>
    </property>

If use gpcopy, does the source table and target table need to be identical?

Does it for creating target in GPDB6 with partition while not with source table in GPDB5?

So the question is how to load data from a no-partitioned table into a partitioned table.

------ GP5 -----

gpadmin=# SELECT * from gp_toolkit.gp_bloat_diag where bdirelid = 1249;
 bdirelid | bdinspname |  bdirelname  | bdirelpages | bdiexppages |                bdidiag
----------+------------+--------------+-------------+-------------+---------------------------------------
     1249 | pg_catalog | pg_attribute |         544 |          43 | significant amount of bloat suspected
(1 row)

gpadmin=# VACUUM pg_attribute;
gpadmin=# SELECT * from gp_toolkit.gp_bloat_diag where bdirelid = 1249;
 bdirelid | bdinspname | bdirelname | bdirelpages | bdiexppages | bdidiag
----------+------------+------------+-------------+-------------+---------
(0 rows)

------ GP6: -----

gpadmin=# SELECT * from gp_toolkit.gp_bloat_diag where bdirelid = 1249;
 bdirelid | bdinspname |  bdirelname  | bdirelpages | bdiexppages |                bdidiag
----------+------------+--------------+-------------+-------------+---------------------------------------
     1249 | pg_catalog | pg_attribute |         390 |          16 | significant amount of bloat suspected

gpadmin=# vacuum FREEZE pg_attribute;
VACUUM
gpadmin=# analyze pg_attribute;
ANALYZE
gpadmin=# SELECT * from gp_toolkit.gp_bloat_diag where bdirelid = 1249;
 bdirelid | bdinspname |  bdirelname  | bdirelpages | bdiexppages |                bdidiag
----------+------------+--------------+-------------+-------------+---------------------------------------
     1249 | pg_catalog | pg_attribute |         390 |          16 | significant amount of bloat suspected

2021-11-23 19:43:46.528056 UTC,"ajones2","ajones2",p12654,th-1991804800,"127.0.0.1","53756",2021-11-23 19:43:42 UTC,0,con17,,seg-1,,,,sx1,"LOG","00000","LDAP login failed for user ""uid=ajones2,ou=people,dc=dc1,dc=nebula,dc=local"" on server ""192.168.1.82"": Invalid credentials",,,,,,,0,,"auth.c",2384,

2021-11-23 19:43:46.528139 UTC,"ajones2","ajones2",p12654,th-1991804800,"127.0.0.1","53756",2021-11-23 19:43:42 UTC,0,con17,,seg-1,,,,sx1,"FATAL","28000","LDAP authentication failed for user ""ajones2""","Connection matched pg_hba.conf line 92: ""host     all     ajones2 0.0.0.0/0       ldap ldapserver=192.168.1.82 ldapbasedn=""ou=people,dc=dc1,dc=nebula,dc=local"" ldapbinddn=""cn=admin,dc=dc1,dc=nebula,dc=local"" ldapbindpasswd=""SuperSecretPassword"" ldapsearchattribute=""uid"" """,,,,,,0,,"auth.c",318, 

This is printed out plaintext in the log.  It's also of course written plaintext in the pg_hba.conf using this method, so this doesn't seem like so much of a leak.To speculate, maybe this is a larger issue if the customer is doing some kind of log shipping via SNMP or something